Methods and systems for secure user authentication

ABSTRACT

Methods and systems for secure user authentication utilizes OTP generation and validation techniques in which the shared secret for generating the OTP is not stored in the user&#39;s mobile device but instead is dynamically synthesized based on a PIN that activates the OTP generation and the personalized OTP data. The client software has no knowledge of what the correct PIN should be and always generates a normal looking OTP based on whatever PIN is entered, and the only way to learn whether or not the OTP is correct is to submit it during user login. By limiting the number of failed login attempts before the account is locked, brute-force attacks via the online channel will fail, and further, brute-force attacks to uncover the correct PIN for generating the correct OTP offline will also fail even if a hacker steals the user&#39;s mobile device and extracts the data inside for offline hacking, because there is nothing on the client that contains the PIN or encrypted by the PIN.

PRIORITY APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/749,230 filed Dec. 9, 2005, entitled “METHODS AND SYSTEMS FOR SECUREUSER AUTHENTICATION”, and U.S. Provisional Application No. 60/784,970filed Mar. 22, 2006, entitled “METHODS AND SYSTEMS FOR SECURE USERAUTHENTICATION”, each of which is incorporated herein by this reference.

FIELD OF THE INVENTION

The present invention relates generally to the field of secure userauthentication, and more particularly to the secure use of one timepasswords (OTPs) for user authentication, for example, for mobile phonebanking, online banking, and access to self-service financialtransaction terminals, such as automated teller machines (ATMs), as wellas a challenge-response validator to provide mutual authenticationbetween a user and a website, email or other channel of communication.

BACKGROUND OF THE INVENTION

A current approach to authenticating individuals to electronic servicesover remote channels utilizes the equivalent of what is commonly knownas the password portion of a login password and changes for everyaccess. This approach is known as a one time password (OTP) solution.Current attempts to employ OTP solutions on mobile platforms, such asmobile phones, PDA's and the like are plagued by inherent weaknesses tothe operating environment. For example, currently offered OTP solutionsenable unauthorized persons to download viruses, spyware, etc. to mobileplatforms that potentially compromise the secrets that are utilizedwithin the OTP in much the same way as they do on personal computers.There is a present need for an OTP solution that overcomes suchweaknesses.

SUMMARY OF THE INVENTION

It is a feature and advantage of the present invention to providemethods and systems for secure user authentication using OTP generationand validation techniques in which the shared secret for generating theOTP is not stored in the user's mobile device but the shared secret forgenerating the OTP is instead dynamically synthesized based on a PINthat activates the OTP generation and the personalized OTP data.

It is a further feature and advantage of the present invention toprovide methods and systems for secure user authentication using OTPgeneration and validation techniques in which the client software has noknowledge of what the correct PIN should be and the only way to learnwhether or not an OTP is correct is to submit it during user login, suchthat limiting the number of failed login attempts before the account islocked assures failure of a brute-force attack via the online channel.

It is another feature and advantage of the present invention to providemethods and systems for secure user authentication using OTP generationand validation techniques in which brute-force attacks to uncover thecorrect PIN for generating the correct OTP offline will also fail evenif a hacker steals the user's mobile device and extracts the data insidefor offline hacking, because there is nothing on the client thatcontains the PIN or encrypted by the PIN.

It is another feature and advantage of the present invention to providemethods and systems for secure user authentication using OTP generationand validation techniques in which OTP PIN change can be done completelyon the server side, since there is no need for the client to know thePIN.

It is an additional feature and advantage of the present invention toprovide methods and systems for secure user authentication using OTPgeneration and validation techniques which can be implemented insoftware, for example, for mobile phones, PDAs, PCs or with customhardware OTP tokens.

It is a still further feature and advantage of the present invention toprovide methods and systems for secure user authentication using OTPgeneration and validation techniques to defeat threats of phishing emailand spoofed websites.

To achieve the stated and other features, advantages and objects,embodiments of the present invention employ computer hardware andsoftware, including, without limitation, instructions embodied inprogram code encoded on machine readable medium, to provide methods andsystems for secure user authentication using OTP generation andvalidation techniques in which the shared secret for generating the OTPis not stored in the user's mobile device but instead is dynamicallysynthesized based on a PIN that activates the OTP generation and thepersonalized OTP data. The client software has no knowledge of what thecorrect PIN should be and always generates a normal looking OTP based onwhatever PIN is entered, and the only way to learn whether or not theOTP is correct is to submit it during user login, for example, to afinancial institution web application such as online banking. Bylimiting the number of failed login attempts before the account islocked, brute-force attacks via the online channel will fail. Further,brute-force attacks to uncover the correct PIN for generating thecorrect OTP offline will also fail even if a hacker steals the user'smobile device and extracts the data inside for offline hacking, becausethere is nothing on the client that contains the PIN or encrypted by thePIN.

Additional objects, advantages and novel features of the invention willbe set forth in part in the description which follows, and in part willbecome more apparent to those skilled in the art upon examination of thefollowing, or may be learned from practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart that illustrates an example of the process ofsecure user authentication using a one-time password for embodiments ofthe invention.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the invention,one or more examples of which are illustrated in the accompanyingdrawings and in Appendices A through D hereof. Each example is providedby way of explanation of the invention, not as a limitation of theinvention. It will be apparent to those skilled in the art that variousmodifications and variations can be made in the present inventionwithout departing from the scope or spirit of the invention. Forexample, features illustrated or described as part of one embodiment canbe used on another embodiment to yield a still further embodiment. Thus,it is intended that the present invention cover such modifications andvariations that come within the scope of the invention.

Embodiments of the invention utilize an open standard for the OTPalgorithm itself based, for example, on algorithms and standards such asthose developed by the initiative for Open AuTHentication or OATHconsortium. Unique aspects of embodiments of the invention add value,for example, via the manner in which secrets are distributed, identifiedand accessed within the actual operation of the solution. In otherwords, embodiments of the invention add value to the entire activationand usage process which provides a level of security above and beyondthat which would normally be available in existing mobile platforms.

A solution provided by embodiments of the invention uses a noveltechnique that eliminates the need to store a complete shared secret ona user's mobile device, such as a mobile phone, for the OTP generation.Instead, the shared secret is generated dynamically every time the useruses the OTP application on the mobile phone with some type of PIN, andthe PIN combined with some part of a secret unique to every user isstored on the phone. Thus, in embodiments of the invention, the sharedsecret is generated based on PIN input and the personalized OTP data, sothat the mobile phone itself does not know or need to know the correctPIN.

Accordingly, if an unauthorized person who does not know the user's PINgains possession of the user's mobile phone and enters an incorrect PINusing a brute-force technique starting, for example, with 0000 or thelike, each time that person enters such a PIN, he or she will get an OTPvalue but will not know whether or not the OTP is correct. It would benecessary for such an unauthorized person to actually enter that OTPthrough some kind of login attempt, for example, to an online financialservices application to actually find out whether or not that OTP iscorrect. Further, the financial institution providing the onlinefinancial services application has control on the server side over thenumber of unsuccessful login attempts a user is allowed to make. Thus, abrute-force technique would not work in trying to find a PIN or find aset secret for OTP generation according to embodiments of the invention.

For example, if three incorrect PINs are entered, the financialinstitution server identifies that and locks up the user's account.Specifically, assume, for example, that three successive incorrect PINvalues are entered incorrectly into the OTP application on the user'smobile phone. Assume further that each time the mobile phone generatesan OTP value it is in turn entered in an attempt to login to the onlinefinancial services application. The financial institution's serverdetects entry of the three successive incorrect OTP values and locks outthe user's account until the user coordinates with customer service andidentifies and proves his or her identity. It is to be understood, ofcourse, that the number of times one can enter an incorrect OTP valuebefore the account is locked is parameterized and configurable on theserver side.

In embodiments of the invention, the OTP is generated on the user'sdevice, such as the user's mobile phone, and thereafter the user entersthat OTP into whatever device is employed in the channel by which theuser accesses an application, such as a financial institution'sapplication. The device can be, for example, a personal computer, alaptop computer, a PDA, a BLACKBERRY device, a phone, an ATM or thelike. A key aspect of embodiments of the invention is that the mobiledevice does not contain the shared secret. Therefore, if an unauthorizedperson, for example, simply performs a memory dump on the user's mobilephone and replicates the mobile phone without knowledge of the user'sPIN, the mobile phone is totally useless. While entry of an incorrectPIN on the mobile phone will generate some random, incorrect OTP value,the unauthorized person will not know whether or not the generated OTPvalue is incorrect until he or she attempts to use it to login to thefinancial institution application.

Many currently available commercial solutions have the complete sharedsecret and secret encryption PIN checksum on the user's mobile phone. Insuch solutions, a brute-force technique can be used by an unauthorizedperson to find the PIN that matches the checksum and enables such personto find and decrypt the encrypted secret in the phone for OTPgeneration. That is a serious weakness of such commercial solutionswhich is eliminated by the unique approach of embodiments of theinvention. Other currently available commercial solutions simply storethe shared secret on the user's mobile phone. In such solutions, theshared secret may be encrypted, but it is typically encrypted withanother key that is also stored on the user's phone. That is likewise aserious weakness, because if the phone is compromised, all of thatinformation can be extracted by an unauthorized person who then hassufficient information to replicate the user's OTP environment.

An important aspect of embodiments of the invention is implementation ofa combined event-time windowing solution, as well as a number of otherdifferent counter options, within the OTP solution. The OATH algorithmitself primarily focuses on what is referred to as an event based countor increment. There is a shared secret and a counter, and the counterincrements and changes the OTP values that are being generated. Inembodiments of the invention, the shared secret is a cryptogram or a keyfor a cryptographic calculation which is stored on the server side, butnot on the client side. The shared secret on the client side isgenerated in the client for OTP generation when the user enters thecorrect PIN on the client side. Once the OTP generation is complete, theshared secret on the client side is destroyed. Thus, embodiments of theinvention generate the shared secret in the client as opposed to simplydecrypting the shared secret in the client.

In an implementation of embodiments of the invention, since the sharedsecret is a composite value, it is held on the server side and isgenerated on the client side by the value created during client sideactivation in conjunction with the PIN entered by the user when theclient application is activated for OTP generation. On the other hand,the OATH algorithm has the shared secret on both the client and theserver. The OATH algorithm has basically two components, one of which isa static component of the secret which does not change. For example, ina hard token that uses the OATH algorithm, there is a static componentwhich is a very long key, such as 40 bytes, and a moving component whichis a counter. Embodiments of the invention differ from the OATHalgorithm, for example, in respect to the moving part and the staticpart of the secrets in that those aspects are not simply stored on theuser's mobile phone so that unauthorized persons can easily take theuser's phone and duplicate it in order to compromise the user's OTP. Asfar as the OATH algorithm is concerned, the two inputs, i.e., the movingfactor and the static factor, look the same and it does not matter wherethose inputs come from.

The PIN in an implementation of embodiments of the invention is managedon the server side. For example, when a bank customer registers foronline banking services using the one time password implementation forembodiments of the invention, the customer can create a PIN for that onetime value solution. Creation of such PIN is performed by the customeronline interacting with the server. Thus, the server on the backendknows the particular PIN value. Thereafter, when the customer downloadsthe software for embodiments of the invention to the customer's mobilephone and activates it and uses his or her PIN at that point in time,the PIN is used in creating the secret interactively, but the PIN valueis not retained on customer's the phone. Instead, the PIN is retainedonly at the server so that the server knows that when it receives an OTPvalue in the password field, it can then validate the OTP value byrecreating the same secret using the PIN value previously identified tothe server. This implementation utilizes what is referred to as a softPIN approach, as opposed to the hard PIN approach in currently availablesolutions in which the PIN actually resides on the mobile device, whichis a security risk.

OTP algorithms can have a moving portion, which is event based andsimply counting or incrementing, or that employs a clock that can besynchronized between the client device being used to generate the OTPvalue and the backend server. In the latter case, the actual time valuecan be used as the moving factor in place of the event counter insteadof a counter simply incrementing. Those are standard definitions of OTPuse and either the event based aspect utilizing some type of counter orthe time based aspect can be used.

In the event based aspect, the counter (or incrementor) increments everytime a user requests a new OTP value. Thus, every time a user performsan OTP, the counter increments. An area of concern in the use of timesynchronization with mobile devices is a lack of precision from onemobile device to another. In other words, if the clock on the user'smobile phone is not accurate, it may be unlikely that it is synchronizedwith (or within an acceptable window of tolerance) with the back endserver. Therefore, if time based increments are used as the basis ofcreating randomness in OTP values, it may not be possible for the user'smobile phone to match up with what the server thinks is the time, so theOTP value would fail to validate. In other words, if the user's mobilephone is, for example, five minutes different from what the serverthinks the time is, it may be outside the acceptable (i.e.,recognizable) window of tolerance.

A consideration that may dictate a preference for utilizing a time basedvalue rather than an event based value is that once an event is created,it is valid until used and the next event occurs. Accordingly, if anunauthorized person captures that value, he or she can reuse it at somelater point in time if the user does not make contact with the system.However, with a time based value, there is a moving window on the backend server as time progresses, so that when the user generates an OTPvalue based on a moving factor of time, it is only valid until thewindow moves beyond the particular time frame after which itautomatically expires. This automatic aging that occurs when a timebased value is used makes the solution more secure.

In order to take advantage of the use of time based values in thisenvironment in which there are unknown differences between the clientside device and the server with which the user attempts to communicate,an aspect of embodiments of the invention makes the time window greaterbut also incorporates an event based component. Thus, while the serverside window is much larger, because both factors are utilized, a userhas a great deal of flexibility in using the system. In other words, asituation can arise if there is a large time step and no event counterin which virtually every time the user presses the key on the clientdevice to create a new OTP value, he or she can end up with the samevalue because the time window has not changed. However, this situationcannot arise when both factors are used in the solution for embodimentsof the invention.

According to embodiments of the invention, instead of being purely timebased or purely event based, the moving factor is both time and eventbased. Thus, if the time increment is 30 minutes, between, for example,1:00 PM and 1:30 PM according to the clock on the user's mobile phone,the value of 1:00 PM will be used for all OTP values generated.Thereafter, for example, at 1:30 PM, the user's mobile phone incrementsand begins using 1:30 PM for generation of OTP values. However, if theuser performs, for example, a couple of transactions between 1:00 PM and1:30 PM, once the user uses an OTP value, the next value will bedifferent because the event counter changes even though the time windowhas not expired.

In implementations of the invention utilizing the time and event basedcombination, every time the user asks for an OTP value, the counter alsoincrements, so when the user asks, for example, for an OTP at 1:00 PMand the counter is five, an embodiment of the invention takes 1:00 PMand five as the moving factors and creates an OTP value. Thereafter, ifthe user asks for another OTP value at 1:02 PM, the embodiment againtakes 1:00 PM, but the counter is six, so it creates an OTP value basedon that moving factor value which is different. Thus, embodiments of theinvention provide the ability to control expiry of outstanding OTP's butin a manner in which the greater variability of the various clocks isaccommodated.

Two significant aspects of implementations of embodiments of theinvention involve, on the one hand, providing greater security to thesolution by removing the essential secret for OTP generation from theclient platform and on the other hand, addressing concerns about timevariability on mobile platforms by providing an implementation thatcombines the event and time characteristics of the moving component ofthe solution. In the first aspect the OTP shared secret is not stored onthe client side but only on the server, which cannot be done bycurrently available solutions. Further, in implementations of theinvention, the PIN itself is used as part of the algorithm process,while currently available solutions use the PIN simply to unlock anapplication or actually use the PIN internally, for example, to decryptthe secret that is stored in the phone. As previously noted, anunauthorized person can take a user's mobile phone and decrypt it with abrute-force technique because all the information needed is stored onthe phone including the checksum to verify whether the PIN is correct.

As also previously noted, a unique feature of embodiments of theinvention is that there is nothing to enter to decrypt on the clientside. An unauthorized user can enter anything as a PIN and an OTP willbe generated, but he or she cannot know if it is a valid or invalid OTP.Another unique feature is that embodiments of the invention provide asolution to the clock synchronization issues on most of mobile phones.

Another disadvantage of currently available time based commercialsolutions is that an unauthorized person in possession of a user'smobile phone can adjust the time, such as setting it to the next day atthe same time, and then generate an OTP, copy it down, and reset themobile phone back to the current time so that the user does not notice.Thus, the unauthorized user has a time window in the next day to usethat OTP to login to the user's account without alerting the userbecause it is all time based and the clock is not locked and can easilybe adjusted. However, because embodiments of the invention utilize acombination of both event and time, even if an unauthorized personchanges the clock, the event is different (i.e., when an OTP isgenerated, the event counter increases) so when an OTP is requested at alater time, since the event counter changes, the OTP is different. Thus,it is useless for an unauthorized person to attempt to adjust the clock.

An additional aspect of embodiments of the invention includesanti-phishing, which is also a method that can be used to support mutualauthentication, and which adds, for example, a “Web Site Verifier”function to the OTP client application on the mobile phone and a“Challenge Web Site” button to the login page that will allow thecustomer to check if the server is genuine before entering his or herOTP. Thus, a spoofed web site from a phishing scam will not be able toobtain a user's OTP without answering the challenge correctly. In theanti-phishing aspect, the web site verifier function uses a standardchallenge-response technique to authenticate the web site, with thecustomer device generating a challenge and the web server producing aresponse to prove that it knows the customer's OTP shared secret. Inorder to safeguard the shared secret from reverse engineering, thetechnique used for generating the response is a truncated one-way hashfunction.

In the anti-phishing aspect of embodiments of the invention, wheneverthe user is not sure if the web site is genuine, the user can enter onlyhis login ID and click on the “Challenge Web Site” button at the loginpage, and the web site presents a screen/pop up box that allows the userto enter a challenge code generated by his OTP token's “Web SiteVerifier”. The user uses his mobile phone to select the “Web SiteVerifier” function in his OTP client application to generate a challengecode. In order to avoid replay attacks, for example, a random number isgenerated by the “Web Site Verifier” function of the OTP client softwareas the challenge code. The user enters the generated challenge code fromhis mobile phone OTP client software into the web site's challenge fieldand clicks “Submit Challenge”, and the Web site displays a response codecorresponding to the submitted challenge. The user then enters theresponse code from the web server into his mobile phone's “Web SiteVerifier”, and the “Web Site Verifier” function on the mobile phone OTPclient software returns a “Yes/No” answer to let the user know if theweb site is genuine or not.

In the anti-phishing aspect, the “Challenge web site” button can beplaced on other web pages after the initial login page to allow the userto challenge the web site at anytime. This is useful, for example, for auser who does not perform the challenge during login and later decidesto check before performing a sensitive transaction such as externalmoney transfer. This is also useful, for example, if the user receivesan update code from the web site during a session (see, e.g., discussionof the policy driven OTP aspect below for how the update code works) andwishes to make sure the web site is genuine before entering the updatecode to his OTP device. A feature of the anti-phishing aspect is, forexample, combined usage for mutual authentication in which, with the website verifier, the user can authenticate the web site before giving outany sensitive data such as an OTP that is susceptible to phishing attackif the OTP algorithm is pure event-based. On the other hand, the websitecan authenticate the user based on the user's OTP. In this way,two-way/mutual authentication can be achieved.

Another aspect of the invention utilizes embodiments of the inventionfor defeating phishing email, which involves, for example, generating aone-time code using the knowledge of the user's OTP shared secret in theOTP server and including that one-time code in all legitimate emailcommunications from the financial institution to its customers with thefinancial institution's mobile OTP. A customer who receives an emailfrom the financial institution can enter that code into the mobile OTPapplication to verify that the email came from the financialinstitution. Since the phishing email attackers do not know the sharedsecret of the user, they cannot generate the correct code to fake afinancial institution email.

The anti-phishing email aspect of embodiments of the invention uses anarbitrary challenge code generated for every email that a financialinstitution sends out to its clients. This challenge code, also referredto as an e-code, can be highlighted with bold font or embedded ingraphics or presented in some other fashion designed to catch the user'sattention when it is included in the email. Inside the email there is,for example, a URL link that is personalized for the particular user, soif the user likes the email contents and is interested in the promotion,the user can click on the URL link and go to a website.

The e-code that is included in the email can be used with the OTP tokenpreviously described herein. The user can enter the e-code as achallenge, and a response, also referred as an e-response code, isgenerated off-line completely on the user's mobile device. When the userclicks on the URL link in the email, the user goes to the website, andthe website displays a response code. If the response code displayed onthe website matches the e-response code generated by the user's OTPdevice, then the user knows the website is good. Otherwise, it isprobably a spoofed website.

Assume that an unauthorized third party intercepts the user's email andgoes to the website first and gets the response code and replays it in aspoofed site. An embodiment of the invention employs a time-basedchallenge-response algorithm so that the response code is different, forexample, every “x” minutes. For instance, if the time “x” is set to 60minutes or 60 seconds, the response code changes every hour or everyminute. So, assuming the time “x” is set to 60 minutes, if anunauthorized third party harvests a response code, the e-response codechanges after an hour and defeats the spoofed site thereafter.

The time-based challenge-response algorithm for embodiments of theinvention eliminates 90% of such attacks. However, there is still apossibility that someone could try to defeat the time-basedchallenge-response mechanism by setting up an automated proxy-typespoofed website by which whatever the authentic website presents issimply projected to the user for the user to see. Thus, when the userenters the challenge code, it is simply forwarded to the authentic site,and the authentic site would generally respond.

In order to defeat such an automated proxy type spoofed website, whenthe e-response code is presented, embodiments of the invention place thee-response code in some type of a Java display-rendering applet that isvery difficult for an unauthorized party to cause to be automaticallyharvested and re-displayed in a spoof site. In other words, it becomesvirtually impossible for the unauthorized party in real time to simplytake the output and place it back in the spoof site to fool the user.Thus, according to the anti-phishing email aspect of the invention, whenthe user receives the correct response, he or she can have a high levelof confidence that the website is real and that he or she can proceed tologin safely.

On the other hand, if the user still has doubts about the authenticityof the website, the anti-phishing email aspect for embodiments of theinvention employs another mechanism previously described herein. Thismechanism is the challenge-the-website function using a random challengecode, also referred to as a w-code. The OTP token for embodiments of theinvention has another function for the challenge-the-web site typemutual authentication. Thus, the user selects the challenge-the-web sitefunction and generates a challenge code. The financial institution'swebsite has a challenge-the-website button on which the user clicks andtransitions to a webpage that allows the user to enter the challengecode known as the w-code. The user then clicks on “submit” and receivesa response. If the response matches the challenge-the-website responsegenerated by the user's OTP device, the user knows that the website isauthentic. The user can use this mechanism at any time during thesession to prevent an unauthorized party's attempt to hijack the user'ssession.

Turning again to the verify function for the anti-phishing email aspectof embodiments of the invention, when the user clicks on the link in theemail, it is not necessary for the user to enter a user ID because thelink in the email is personalized for the user. In other words, the linkitself has parameters that contain both the e-code and, for example, ahash of the user ID or something that uniquely identifies the user tothe financial institution. The financial institution knows what theuser's e-code is and generates a corresponding response. The user seesthe e-code in the email and enters the e-code into the user's OTP tokenand generates a response. If that response matches the one displayed tothe user on the website, then the website is authentic. That is trueeven if a pass-through proxy-type attack is used, because when thefinancial institution presents its response to the user, it is displayedusing technology employed to make it extremely difficult for someone toharvest the e-response code and replay it back to the user.

Turning again to the challenge function for the anti-phishing emailaspect of embodiments of the invention, as previously described herein,when a user uses his or her OTP token to connect directly to his or herfinancial institution website (as opposed to checking on email), theuser normally enters his or her user ID and then clicks on thechallenge-the-website function and verifies that the site is authenticbefore entering his or her one-time password. Thus, thechallenge-response algorithm for embodiments of the invention deployedin the user's OTP token allows the user to perform a two-way userauthentication. Not only does the website verify that the user isauthentic, but the user also verifies that the website is authenticbefore he or she proceeds with entering anything. Further, as previouslydiscussed, the complete OTP shared secret is only on the server side.When the user generates a challenge and response, he or she must stillenter his or her PIN to generate the OTP shared secret on the fly andgenerate the correct response.

A further aspect of embodiments of the invention includes policy drivenOTP that relates to the generation of OTP values. The ability to updatethe OTP shared secret, algorithm type, and security policy by afinancial institution, such as a bank, at will which provides anexcellent way to reduce the possibility of compromised OTP devices. Thisis especially true for software based OTP implementation that runs onuser devices such as mobile phones, PDAs, and PCs. Hackers may useviruses, malware, keyloggers, etc. to monitor and export informationfrom the device for illegal activities. In the case of static passwords,the security policy imposes password composition rules and periodicpassword change to reduce the possibility of password compromise.However, it adds burdens to the user to use difficult-to-rememberpasswords and to change them regularly. This may be acceptable forcorporate employees, but it may not be acceptable for individual bankcustomers. The policy driven OTP system for embodiments of the inventionsolves this problem with an innovative solution that alters the OTPwithout requiring the user to change his OTP PIN.

In the policy driven OTP aspect of embodiments of the invention, an“Update” function is added to the OTP client software on the mobilephone to support modification of OTP shared secret components andsecurity policy, such as which OTP algorithm to use via an update code.The financial institution can initiate an OTP policy change from the OTPmanagement system and issue an update to any user at any time based onbusiness rules, security policy change, or threat detections. Forexample, the financial institution can push an update to the user inevery 20 good logons, every month, when the user account has many badlogin attempts prior to the successful login, when the financialinstitution decides to switch from one OTP algorithm to another, etc.The update code can be delivered to the user during a logon session(e.g. a user has login successfully) or via an alternative channel (e.g.email, PIN mailer, etc.). Note that the update code is usedincrementally to modify the existing shared secret components andsecurity policy of the OTP client software. This makes intercepting theupdate code useless to the attacker because it needs to combine with theexisting shared secret components and PIN to generate the new sharedsecret.

In the policy driven OTP aspect of embodiments of the invention, thefinancial institution can manage the OTP tokens as if managing regularstatic passwords. For examples, the financial institution can enforceregular password change without requiring the user to change his OTPPIN. The OTP token can be “expired” by the financial institution atanytime by issuing an update code to that token. Changing the underlyingshared secret and/or components of the OTP is like changing a staticpassword. To the user, it is as simple as entering the received updatecode. The beauty of this approach is that the user can still use thesame old PIN to generate OTP after the update, but the generated OTPwill be totally different because the shared secret, parameters, and/orOTP algorithm underneath are no longer the same. In addition, if aparticular OTP algorithm is no longer secure or it has performanceissues, the financial institution can issue an update code to switch thecharacteristics of the OTP client software to use a different algorithmor OTP factor combination. In this way, the financial institution cancontrol everything related to the OTP client software/token from the OTPmanagement server using the update code without having to upgrade theOTP client software. In addition, mutual authentication can be performedbetween user and website by combining the anti-phishing aspect and thepolicy driven OTP aspect of embodiments of the invention.

Various preferred embodiments of the invention have been described infulfillment of the various objects of the invention. It should berecognized that these embodiments are merely illustrative of theprinciples of the present invention. Numerous modifications andadaptations thereof will be readily apparent to those skilled in the artwithout departing from the spirit and scope of the present invention.

1. A method for secure user authentication using a one-time password,comprising: storing a portion of a secret unique to the user forgenerating a client-side version of a correct one-time password value ona first client-side computing device responsive to receiving entry of auser's correct PIN value, said client-side version of the correctone-time password value being based at least in part on the entered PINvalue and at least in part on both a client-side time incrementor and aclient-side event incrementor, wherein the portion of the secret uniqueto the user stored on the first client-side computing device excludesthe user's correct PIN value on which generation of the client-sideversion of the correct one-time password value is based at least in partand wherein a putative one-time password value is always generated inresponse to entry of any purported PIN value of the user on the firstclient-side computing device; storing the complete secret unique to theuser for a cryptographic calculation of a server-side version of thecorrect one-time password value for the user on a server computer,wherein the complete secret unique to the user stored on the servercomputer comprises the user's correct PIN value and an algorithm forcalculating the server-side version of the correct one-time passwordvalue based at least in part on the user's correct PIN value and atleast in part on both a server-side time incrementor and a server-sideevent incrementor that are synchronized, respectively, with theclient-side time incrementor and the client-side event incrementor;receiving entry on the first client-side computing device of a purportedPIN value of the user; dynamically synthesizing a putative one-timepassword value on the first client-side computing device based at leastin part on the purported PIN value of the user, the portion of thesecret unique to the user stored on the first client-side computingdevice that excludes the user's correct PIN value, and both theclient-side time incrementor and the client-side event incrementor;receiving entry of the putative one-time password by the server computerduring a login attempt from a second client-side computer;cryptographically calculating the server-side version of the correctone-time password value by the server computer based at least in part onthe complete secret unique to the user and on both the time incrementorand the event incrementor in response to receiving entry of the putativeone-time password value; and allowing the login when the putativeone-time password corresponds to the cryptographically calculatedserver-side version of the correct one-time password value.
 2. A systemfor secure user authentication using a one-time password, comprising: afirst client-side computing device having a processor coupled to memory,the first client-side computing device processor being programmed for:storing a portion of a secret unique to the user for generating aclient-side version of a correct one-time password value on the firstclient-side computing device responsive to receiving entry of a user'scorrect PIN value, said client-side version of the correct one-timepassword value being based at least in part on the entered PIN value andat least in part on both a client-side time incrementor and aclient-side event incrementor, wherein the portion of the secret uniqueto the user stored on the first client-side computing device excludesthe user's correct PIN value on which generation of the client-sideversion of the correct one-time password value is based at least inpart, and wherein a putative one-time password value is always generatedin response to entry of any purported PIN value of the user on the firstclient-side computing device; a server computer having a processorcoupled to memory, the server computer processor being programmed for:storing the complete secret unique to the user for a cryptographiccalculation of a server-side version of the correct one-time passwordvalue for the user on the server computer, wherein the complete secretunique to the user stored on the server computer comprises the user'scorrect PIN value and a key for the cryptographic calculation of theserver-side version of the correct one-time password value based atleast in part on both a server-side time incrementor and a server-sideevent incrementor that are synchronized, respectively, with theclient-side time incrementor and the client-side event incrementor; thefirst client-side computing device process being further programmed for:receiving entry on the first client-side computing device of a purportedPIN value of the user; dynamically synthesizing a putative one-timepassword value on the first client-side computing device based at leastin part on the purported PIN value of the user, the portion of thesecret unique to the user stored on the first client-side computingdevice that excludes the user's correct PIN value, and both theclient-side time incrementor and the client-side event incrementor; theserver computer processor being further programmed for: receiving entryof the putative one-time password by the server computer during a loginattempt from a second client-side computer; cryptographicallycalculating the server-side version of the correct one-time passwordvalue by the server computer based at least in part on the completesecret unique to the user and on both the time incrementor and the eventincrementor in response to receiving entry of the putative one-timepassword value; and allowing the login if when the putative one-timepassword corresponds to the cryptographically calculated server-sideversion of the correct one-time password value.